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SHARED COMMUNICATIONS PROTOCOL 
LAYER FOR INTERFACING BETWEEN 
WIRELESS NETWORKS 

CROSS-REFERENCE TO RELATED 
APPLICATION 

The subject matter of the present application is related to 
subject matter disclosed in U.S. Ser. No. 08/680,225 filed on 
Jul. 11, 1996. 

FIELD OF THE INVENTION 

This invention relates to communications between wire- 
less networks and, more particularly, to interfaces control- 
ling communications between wireless networks. 

BACKGROUND OF THE INVENTION 

Advancements in the fields of electronics and communi- 
cations have permitted the introduction and commercializa- 
tion of many new types of communication systems. Infor- 
mation can be affordably communicated to locations and in 
manners previously not possible or affordable. 

The field of cellular telephony is exemplary of a commu- 
nication system that has been made possible due to such 
advancements. A fixed, wireline connection is not required 
between a transmitting station and a receiving station in a 
cellular, or other radio telephonic, communication system to 
effectuate communications between the stations. Because a 
"wireless" connection is formed between the transmitting 
station and the receiving station, use of such a communica- 
tion system is particularly advantageous to effectuate com- 
munications when a wireline connection cannot be conve- 
niently or practically formed. 

Various different types of cellular, and other 
radiotelephonic, communication systems have been imple- 
mented and others have been proposed. In many parts of the 
world, for instance, macrocellular communication networks 
have been installed. Such networks permit mobile subscriber 
units positioned anywhere within the area encompassed by 
the macrocellular networks to communicate pursuant to the 
macrocellular communication network. A macrocellular 
communication network typically includes a large number 
of base stations positioned at spaced-apart locations 
throughout a geographic area. As a mobile subscriber unit 
moves throughout the geographical area, communications 
with the mobile subscriber unit are "handed-off" to succes- 
sive ones of the base stations. In one type of cellular 
communication system, a Global System for Mobile (GSM) 
communications system, control circuitry, including mobile 
services switching centers (MSCs) and base stations con- 
trollers (BSCs), controls communications between the base 
stations and the mobile subscriber unit. And, location 
registers, including a home location register (HLR) associ- 
ated with the mobile subscriber unit, maintain a registry of 
the positioning of the mobile subscriber unit in a network. 

Microcel hilar communication networks have also been 
developed and implemented. A Digital Electronic Cordless 
Telephone (DECT) system is exemplary of a microcellular 
communication network. A microcellular communication 
network, analogous to a macrocellular communication 
network, also permits wireless communications to be effec- 
tuated with a mobile subscriber unit. The area encompassed 
by a microcellular communication network is, however, 
typically much smaller than the area encompassed by a 
macrocellular communication network. 

The costs associated with a microcellular communication 
network are generally less than the costs associated with a 
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macrocellular communication network. However, because 
microcellular communication networks generally encom- 
pass limited areas, a single business, or other operator, might 
be required to construct more than one microcellular com- 

5 munication network to encompass a desired area in which 
microcellular communications are to be permitted. 

For instance, a microcellular communication network 
might be constructed to provide microcellular communica- 
tion coverage encompassing a single building. A mobile 

10 subscriber unit regularly registered to communicate pursu- 
ant to the microcellular communication network must be 
within the building, i.e., the area encompassed by the 
microcellular communication network, to communicate 
therethrough. 

15 It is sometimes desirable to permit a mobile subscriber 
unit, regularly registered in one microcellular communica- 
tion network (the "home" network), also to communicate in 
another microcellular communication network (the "visited" 
network). For instance, a business might have separate office 

20 locations, requiring separate microcellular networks to be 
installed for each of the separate office locations. It is 
sometimes desirable, in such instances, to permit personnel 
regularly located at one of the office locations to be able to 
communicate by way of a microcellular communication 

25 network even when the personnel are temporarily positioned 
at the other one of the office locations. 

By providing communication links between the separate 
microcellular networks, registration, and other, information 
pertaining to the mobile subscriber unit stored at the "home" 
microcellular communication network can be used to permit 
communications with the mobile subscriber unit, even when 
the mobile subscriber unit is positioned in an area encom- 
passed by the "visited" microcellular communication net- 

^ work. 

Various proposals have been set forth to form communi- 
cation links between microcellular networks by way of a 
macrocellular communication network. Such proposals, 
however, have generally been set forth for purposes of call 
4Q control and not for purposes of mobility management. Viz. 
existing proposals for intercoupling the networks have not 
generally pertained to providing wide-area mobility to 
mobile subscriber units of microcellular communication 
networks. 

45 Additionally, existing proposals generally require direct 
connections between the microcellular and macrocellular 
communication networks. As the operators of the macrocel- 
lular and microcellular communication networks might well 
be different entities, the conventional requirement for direct 

50 connections between the microcellular communication net- 
works might sometimes be problematical. 

A manner by which better to provide wide -area mobility 
to a mobile subscriber unit to increase the mobility permitted 
of the mobile subscriber unit would be advantageous. 

55 Additionally, a manner by which to provide for the 
communication of mobility management information 
between a microcellular and macrocellular communication 
network without requiring direct connections therebetween 
would also be advantageous. 

60 It is in light of this background information related to 
mobility management in a cellular communication system 
that the significant improvements of the present invention 
have evolved. 

65 SUMMARY OF THE INVENTION 

The present invention advantageously provides a method, 
and associated apparatus, for facilitating communications to 



12/22/2003, EAST Version: 1.4.1 



US 6,631,140 Bl 



25 



and from a mobile subscriber unit operable in a microcel- 
lular communication network when the mobile subscriber 
unit roams into an area encompassed by a 'Visited" micro- 
cellular communication network other than the "home" 
network in which the mobile subscriber unit is regularly s 
registered. 

Wide -area mobility management functions available in a 
macrocellular network are provided to microcellular net- 
works by coupling the microcellular networks to the mac- 
rocellular network. Wide-area mobility is thereby provided 10 
to a mobile subscriber unit operable in a microcellular 
communication network. The wide -area management func- 
tions provided to the microcellular communication network 
permits a mobile subscriber unit to communicate by way of 
a microcellular communication network even when it roams 15 
into an area encompassed by a "visited" network. 

When the macrocellular communication network is 
formed of a Global System for Mobile communications 
(GSM) network, the microcellular communication networks 
include the mobility servers which appear, to the GSM 20 
network, to be mobile services switching centers (MSCs) of 
the GSM network. Mobility management normally provided 
to the mobile services switching centers of the GSM net- 
work are provided to the mobility servers of the microcel- 
lular networks. Signaling between the mobility server and 
the macrocellular communication network permits, for 
example, calls to be placed to and from a mobile subscriber 
unit when the subscriber unit roams beyond the microcel- 
lular communication network in which the subscriber unit is 
regularly registered. Location updating of the position at 30 
which the subscriber unit roams is similarly also effectuated. 

In one aspect of the present invention, location informa- 
tion related to the position of a mobile subscriber unit is 
updated when the, mobile subscriber unit roams into an area 35 
encompassed by a microcellular communication network 
other than the network in which the subscriber unit is 
regularly registered. A mobility server of such "visited" 
microcellular network receives indications of the position- 
ing of the subscriber unit and provides information indica- 4Q 
tive thereof to a home location register (HLR) of the 
macrocellular communication network. The home location 
register (HLR) provides the visited mobility server with 
subscriber data related to the mobile subscriber unit and 
orders the "home" mobility server of the subscriber unit's 45 
home network to deregister the subscriber unit therefrom. 

In another aspect of the present invention, calls originated 
at a Public Switched Telephone Network (PSTN) to be 
terminated to a mobile subscriber unit of the "home" micro- 
cellular communication network are routed to the subscriber 50 
unit when the subscriber unit roams beyond the "home" 
network and into a "visited" network. In one exemplary 
routing method, the call is routed via the home microcellular 
communication network to a gateway mobile services 
switching center (GMSC) of the macrocellular communica- 55 
tion network, and the GMSC interrogates the home location 
register of the macrocellular network to obtain routing 
information to route the call to the roaming subscriber unit. 
The HLR requests and receives information from the mobil- 
ity server of the "roaming" microcellular network. Such 60 
information is provided to the GMSC, and the call is routed 
to the mobile subscriber unit, to be terminated thereat. 

In another aspect of the present invention, a call origi- 
nated at a roaming, subscriber unit is routed to a subscriber 
unit registered in the macrocellular communication network. 65 
And, in yet another aspect of the present invention, calls are 
placed between a mobile subscriber unit positioned in a 



"home" microcellular network to a mobile subscriber unit 
roaming in a "visited" microcellular communication net- 
work. And, in yet another aspect of the present invention, the 
mobile subscriber unit forms a dual-mode subscriber unit, 
operable in both a microcellular network and a macrocellu- 
lar network. Calls are placed, or received, by the subscriber 
unit when the subscriber unit is positioned in its "home" 
microcellular network, a visited microcellular network, or 
within an area encompassed only by the macrocellular 
network. 

With respect to foregoing aspects of the present invention, 
the mobility management signaling entering the macrocel- 
lular network is screened to protect the functions of the 
macrocellular network from damage. 

Further with respect to foregoing aspects of the present 
invention, a plurality of mobility servers communicate with 
a central server such as an HLR or a debit platform via a 
shared communications protocol layer. 

In these and other aspects, therefore, mobility-enhancing 
apparatus for a first mobility server facilitates communica- 
tion with a mobile subscriber unit. The mobile subscriber 
unit is operable in a first microcellular communication 
network of a communication system having a macrocellular 
communication network and at least the first microcellular 
communication network. The first microcellular communi- 
cation network includes the first mobility server. The 
mobility-enhancing apparatus facilitates communication 
with the mobile subscriber unit, operable in the first micro- 
cellular communication network, in a communication net- 
work other than the first microcellular communication net- 
work. A storage device stores location information 
representative of positioning of the mobile subscriber unit. 
A mobility manager is coupled to the storage device and to 
the macrocellular network. The mobility manager at least 
updates the location information stored in the storage device 
to indicate whether the mobile subscriber unit is positioned 
within range of the first microcellular communication net- 
work. The mobility manager further receives macrocellular 
network-generated data related to the mobile subscriber unit, 
and the network-generated data is used for the updating of 
the location information. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 illustrates a functional block diagram of a com- 
munication system which includes an embodiment of the 
present invention as a portion thereof. 

FIG. 2 illustrates a functional block diagram of a portion 
of the communication system shown in FIG. 1 used during 
operation of an embodiment of the present invention to 
update the location of a mobile subscriber unit when the 
mobile subscriber unit roams into an area encompassed by 
a microcellular communication network other than the 
"home" microcellular network in which the subscriber unit 
is regularly registered. 

FIG. 3 illustrates a functional block diagram of a portion 
of the communication system shown in FIG. 1 used during 
a call to a mobile subscriber unit that has roamed into a 
microcellular communication network other than the 
"home" network in which the subscriber unit is regularly 
registered. 

FIG. 4 illustrates a portion of the communication system 
shown in FIG. 1, used during operation of an embodiment of 
the present invention to route a call originated by a mobile 
subscriber unit when the mobile subscriber unit is positioned 
in an area encompassed by a microcellular communication 
network other than the "home" network in which the sub- 
scriber unit is regularly registered. 
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FIG. 5 illustrates a portion of the communication system invention as a portion thereof. The communication system 

shown in FIG. 1 used during operation of an embodiment of 10 is a multi-network communication system, here shown to 

the present invention to route a call between subscriber units include a macrocellular communication network 12, a first 

positioned in different microcellular communication net- microcellular communication network 14, and a second 

works, S microcellular communication network 16. 

FIG. 6 illustrates in detail an example of a mobility ^ microcellular communication network 12 for pur- 

signaling portion of the mobility servers of FIGS. 1-5. poses of illustration in the enmpkry embodiment, » 

& & r ' formed of a Global Systems for Mobile communications 

FIG. 7 is a block diagram illustrating an exemplary (GSM) network. In other embodiments, the macrocellular 

signaling channel firewall arrangement according to the communication network 12 is alternatively formed of 

present invention. another type of Public Land Mobile Network (PLMN). 

FIG. 8 illustrates the signaling channel firewall arrange- Analogously, the first and second microcellular communi- 

ment of FIG. 7 in greater detail. cation networks 14 and 16, respectively, are, in the exem- 

FIG.9illustratestheoperationofonepartofthescreening pl^ embodiment, formed of Digital Electronic Cordless 

c ** r i-t^ q Telephone (DECT) systems. The microcellular networks 14 

function 01 FIG. ». 15 . „ ti - L r j. T^rr^r . i 

and 16 shall, at times, be referred to as DECT systems. In 

FIG. 10 illustrates a portion of FIG. 9 in greater detail. anQther embodimentj the networks 14 and 16 are alterna . 

FIG. 11 illustrates the operation of another part of the tively formed of other types of Private Telephonic Networks 

screening function of FIG. 8. (PTNs). 

FIG. 12 illustrates the operation of another part of the ^ The macrocellular communication network 12 encom- 

screening function of FIG. 8. passes a macrocellular-region throughout which wireless 

FIG. 13 illustrates generally the operation of the screening communications by way of the network 12 are permitted. In 

function of FIG. 8 with respect to the operation of the conventional manner, the network 12 includes a plurality of 

protocol stack and SS7 signaling channel of FIG. 8. spaced-apart base stations, of which two base stations 18 are 

FIG. 14 illustrates an exemplary database of operations 25 illustrated in the figure. Each base station 18 encompasses an 

that can be screened according to the present invention. area defining a cell 20 The cells 20 defined by the base 

„_ .,. 1 j . L r * stations 18 collectively form the region encompassed by the 

FIG. 15 illustrates an exemplary database of parameters ne twork 12 o r j 

that can be screened according to the present invention. m , * . , , , 

,„ t , . . The base stations are coupled by way of base station 

HI*. 16-1V illustrates specitic values and ranges wined controllels 33 to mobile 

services switching centers (MSCsV 

can be defined in an exemplary parameter database accord- 30 ^ ^ ^ switching 24 and 26 The 

ing to the invention. basc statjon ^^0^ 2 2 are operable, inter alia, to control 

FIG. 20 illustrates an exemplary database for screening operation of the base stations 18 coupled thereto. Control 

origination addresses according to the invention. operations, such as hand-off decisions and channel 

FIG. 21 illustrates an exemplary database for screening 3S allocations, are performed at the controllers 22. Operation of 

destination addresses according to the invention. the base station controllers 22, and the mobile services 

FIG. 22 is a block diagram which illustrates how a switching centers 24 and 26 of the exemplary embodiment 

plurality of mobility servers communicate with HLR via a corresponds generally with operation of such devices in 

concentrator according to the present invention. existing standards specifications. 

FIG. 23 illustrates the concentrator and HLR of FIG. 22 40 ™ c mobile services switching centers 24 and 26 shown in 

in greater detail ^ c ^£ urc are inter-coupled, here indicated by the lines 28. 

r-r^ •« . .i . j . , i The MSCs 24 and 26 are further coupled to a Public 

FIG. 24 illustrates another arrangement according to the Switched Ne(work ^ K are 

present invention wherein a plurality of mobility servers ^ ^ ^e^y, in J flgure . 

communicate with a central server via a concentrator. , . , j , - . 

m _ M .„ t , ^ 45 The GSM network 12 further includes location registers 

FIG. 25 illustrates the concentrator and server of FIG. 24 the homc location rcgistcr (HLR) 36. The HLR 36 

in greater detail ^ coupled lo the MSCs 2 4 and 26 by way of lines 38 and 42, 

FIG. 26 illustrates the operation of the SSN/Socket func- respectively. The HLR 36 is operable in the GSM- 

tion of FIGS. 23 and 25. communication network 12, inter alia, to perform wide-area 

FIGS. 27 and 28 illustrate the operation of the DIA- 50 mobility management functions to facilitate call routing to 

LOGUE ID function of FIGS. 23 and 25. and from mobile subscriber units operable to communicate 

FIG. 29 illustrates a database utilized by the DIALOGUE by w *y of the communication network 12. Such mobility 

ID function. management functions include, for instance, the mainte- 

FIG. 30 illustrates a database used by the SSN/Socket nance °{ a subscriber registry. The subscriber registry con- 

function 55 taiDS m f ormatlon relating to the subscriber units where- 
abouts and status. 

FIG. 31 illustrates a further database used by the DIA- rp, irT n ~, . - . j , f1 . AA , A , 

t nr rip in p. f The HL^ 36 is further coupled, by way of lines 44 and 46, 

LULrUt 1U runction. respectively, to mobility servers 48 and 52 of the DECT 

FIG. 32 illustrates a further database used by the DIA- sys tems 14 and 16, respectively. In an exemplary 

LOGUE ID function. 6Q embodiment, the mobility servers 48 and 52 are based on 

FIG. 33 illustrates a further alternative embodiment of the MD 110 hardware components. Services supported there- 
present invention, wherein the traffic handler is combined from are developed on an Erlang platform. Services per- 
with the screening function of FIGS. 8-21. formed by the mobility servers 48 and 52 include those 

which are conventionally provided by mobility servers of 

DETAILED DESCRIPTION 65 conventional DECT systems. 

Referring first to FIG. 1, a communication system, shown The mobility server 48 is coupled to radio exchange 

generally at 10, includes an embodiment of the present equipment 54 by way of lines 56. The radio exchange 
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equipment 54 includes transceiver circuitry permitting com- 
munication with mobile subscriber units, such as the mobile 
subscriber unit 58. Similarly, the mobility server 52 is 
coupled to radio exchange equipment 62 by way of lines 64. 
Analogous to the radio exchange equipment 54, the radio 5 
exchange equipment 62 includes transceiver circuitry per- 
mitting wireless communications with mobile subscriber 
units positioned within the area encompassed by the DECT 
system 16. 

In one embodiment, the mobile subscriber unit 58 forms 10 
a dual-mode subscriber unit, selectively operable to com- 
municate with both the GSM network 12 and the microcel- 
lular networks 14 and 16. 

The mobility server 48 includes a mobility manager 66 
capable of communicating information with the HLR 36. 
The mobility manager 66 is further coupled to a storage 
device 68 which also forms a portion of the mobility server 
48. Similarly, the mobility server 52 includes a mobility 
manager 72 which is capable of communicating information 
with the HLR 36. The mobility manager is further coupled 
to a storage device 74 which also forms a portion of the 
mobility server 52. The mobility server 48 is further coupled 
to the MSC 24, here indicated by lines 76. And, the mobility 
server 52 is further coupled to the MSC 26, here indicated 
by the lines 78. Both the mobility servers 48 and 52 are 25 
further coupled to a PSTN and provide conventional call 
routing of calls between the PSTN and mobile subscriber 
units which are regularly registered in the respective com- 
munication networks 14 and 16. 

The storage devices 68 and 74 store location information 
related to subscriber units operable in the respective net- 
works associated with the mobility servers 48 and 52, 
respectively. As shall be described below, such location 
information can be updated during operation of an embodi- 35 
ment of the present invention. In one embodiment, the 
storage devices 68 and 74 further store service subscription 
information related to service subscriptions to which the 
subscriber units are subscribed. 

During operation of an embodiment of the present 40 
invention, the wide-area mobility management functions 
provided by the GSM network 12 are further utilized by the 
DECT systems forming the microcellular networks 14 and 
16. Such utilization provides wide -area mobility to mobile 
subscriber units operable in the networks 14 and 16. 45 
Thereby, communications with mobile subscriber units of 
the networks 14 and 16 are permitted when such subscriber 
units roam beyond the areas encompassed by the networks 
in which the subscriber units are regularly registered, viz., 
the subscriber units' "home" network. For instance, when 50 
the mobile subscriber unit 58 roams beyond the microcel- 
lular network 14 and into, for instance, the microcellular 
network 16, the wide-area mobility management functions 
provided by the GSM network 12 are utilized to facilitate 
communications with the "roaming" mobile subscriber unit. 55 
In an embodiment having dual-mode subscriber units, the 
wide-area mobility management functions provided by the 
GSM network are utilized by the subscriber units when 
communicating by way of the networks 14 and 16 and also 
when communicating by way of the GSM network 16. 60 

Mobile application part (MAP) interfaces are introduced 
into the mobility servers 48 and 52, respectively. The MAP 
is specified in European Telecommunication Standard (ETS) 
300599, GSM 09.02 version 4.11.1, November 1995, which 
is hereby incorporated herein by reference. An analogous 65 
standard is the mobility management portion of HA/EIA/ 
IS-41, promulgated by the Telecommunication Industry 



Association (TIA) and the Electronics Industry Association 
(EIA). In one embodiment, five conventional MAP opera- 
tions are supported by the MAP interface. Namely, update 
location (which is termed "registration notification" in 
IS-41), insert subscriber data, delete subscriber data, cancel 
location, and provide roaming number (termed "routing 
request" in IS-41) operations are supported by the MAP 
interface. Such operations are performed, as necessary, to 
permit communications with the subscriber unit when the 
subscriber unit roams beyond its home network. 

Subscription information associated with mobile sub- 
scriber units, such as the subscriber unit 58, operable in the 
DECT network 14 are stored not only in the mobility server 
48 but also in the HLR 36. Services pursuant to the sub- 
scription in the HLR 36, however, need not be defined. But, 
the subscriber unit 58 includes an MSISDN number and an 
IMSI number allocated thereto. The subscription for the 
subscriber unit in the HLR 36 is based on such numbers. 

The mobility server 48 contains tables permitting trans- 
formation between a DECT identity, used to identify the 
subscriber unit in the DECT system 14 and the MSISDN and 
IMSI numbers, used to identify the subscriber unit in the 
GSM network 12. 

The DECT identity, the IMSI, and the MSISDN allocated 
to the subscriber unit 58 are further defined in each mobility 
server, such as the mobility server 52, in each DECT system 
16, or other PTN, in which the subscriber unit 58 is 
permitted to roam. Such information is predefined in the 
mobility servers. Such predefined information further 
includes a predefined service profile which, in one 
embodiment, is not otherwise transferred from the sub- 
scriber units' 58 home mobility server, here server 48, to a 
visited mobility server, here server 52. Each mobility server 
further includes a series of roaming numbers which are 
defined in manners similar to the roaming numbers defined 
in a mobile services switching center or location register of 
a conventional GSM network. Signaling between the MSCs 
24 and 26 and the HLR 36 is routed by using a global title 
(GT) and subsystem number (SSN). Thereby, the mobility 
servers 48 and 52 appear to the HLR 36 as mobile services 
switching centers, similar to the switching centers 24 and 26. 
The mobility servers further include unique MSC/VLR 
addresses, similar to the MSC/VLR addresses which iden- 
tify the MSCs of the macrocellular network 12, 

FIG. 2 illustrates again the HLR 36 of the GSM network 
12 and the mobility servers 48 and 52 of the DECT systems 
14 and 16, respectively. Lines 44 and 46 are again shown to 
couple the HLR 36 with the mobility servers 48 and 52, 
respectively. And, the radio exchange equipment 54 and 62 
are again shown to be coupled to the respective mobility 
servers 48 and 52. When a mobile subscriber unit, here 
subscriber unit 58, roams out of the microcellular network 
14, its home network, and into the microcellular network 16, 
the subscriber unit 58 registers with the mobility server 52. 
The roaming of the subscriber unit is indicated in the figure 
by the arrow 84. The identity of the subscriber unit 58 is 
indexed against a list of subscriber units permitted to roam. 
A subscriber unit 58 is assumed to be listed on such list and 
a transformation between the DECT identity of the sub- 
scriber unit 58 and its corresponding IMSI number is 
performed by the mobility manager 72. 

Second, as indicated by the arrow 86, the mobility server 
52 updates the location information of the subscriber unit 
with the HLR 36. Then, and as indicated by the arrow 88, the 
HLR 36 provides the mobility server 52 with subscriber 
data, namely the IMSI and MSISDN numbers, stored in the 
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HLR 36. And, as indicated by the arrow 92, the HLR 36 
causes the mobility server 48 to deregister the old registra- 
tion of the subscriber unit 58 in the network 14. Thereby, the 
location of the subscriber unit 58 is updated to indicate its 
location in the area encompassed by the microcellular net- 5 
work 16, not the microcellular network 14. 

FIG. 3 illustrates operation of an embodiment of the 
present invention by which a call is routed to the subscriber 
unit 58, regularly registered at the network 14, when the 
subscriber unit 58 roams into the network 16. Elements of 10 
the communication system 10 utilized in the exemplary 
operation of call routing to the roaming, subscriber unit 58 
are shown in FIG. 3 and identified by the same reference 
numerals used to identify such elements in FIG. 1. 

When the mobility server 48 receives a call, such as a call 15 
originated at the PSTN to be terminated at the mobile 
subscriber unit, the identity of the subscriber unit is indexed 
against a list of subscriber units permitted to roam. The 
subscriber unit 58 is assumed to be on the list and marked 
as being roaming beyond the network 14. The mobility 20 
manager of the mobility server 48 translates the DECT 
identity of the subscriber unit into an MSISDN number, and 
the call is routed to the MSC 24, here forming a gateway 
MSC (GMSC). Such routing is indicated in the FIGURE by 
the arrow 102. Then, and as indicated by the arrow 104, the 25 
MSC 24 interrogates the HLR 36 for routing information to 
route the call to the roaming, subscriber unit. 

Responsive to the interrogation, the HLR 36 requests a 
roaming number, MSRN, from the mobility server 52, as 3Q 
indicated by the arrow 106. The mobility server 52 returns 
the roaming number allocated to the subscriber unit 58 to the 
HLR 36, as indicated by the arrow 108. The HLR 36 
thereafter, and as indicated by the arrow 112, returns the 
roaming number allocated to the subscriber unit 58 to the 3S 
MSC 24. Once the roaming number is received at the MSC 
24, the call is routed to the roaming subscriber unit 58, as 
indicated by the arrows 114, by utilizing the roaming num- 
ber. The MSC 24, in one embodiment, generates both a 
transit call data record and a roaming call forwarding record, 4Q 
for billing purposes, if desired, 

FIG. 4 illustrates operation of an embodiment of the 
present invention by which the wide-area management func- 
tions provided by the GSM network 12 of the communica- 
tion system 10 are utilized to facilitate routing of a call 45 
originated at a roaming subscriber unit, here subscriber unit 
52 to a mobile subscriber unit operable in the GSM network. 
Again, elements of the communication system 10 utilized 
during such operation are identified with the same reference 
numerals utilized to identify such elements in FIG. 1. 50 

The subscriber unit 58 originates a call, indications of 
which are received by the radio exchange equipment 62. The 
call request is provided to the mobility server 52 and the 
mobility manager 72 thereof indexes the identity of the 
roaming, subscriber unit against a listing of subscriber units 55 
permitted to roam. The subscriber unit is assumed to be on 
the list and the predefined service profile associated there- 
with is used for the subscriber unit 58. 

The call is set up by way of the MSC 26, here forming a 
gateway MSC (GMSC) and the DECT identity of the 60 
subscriber unit 58 is used as an A-number. The call is 
thereafter routed, in conventional fashion pursuant to the 
GSM network, to be terminated at the mobile subscriber, 
here a mobile subscriber 122. That is to say, the MSC 26 
interrogates the HLR, as indicated by the arrow 124, for 65 
routing information. Such routing information is received at 
the HLR 36 from the MSC 24, as indicated by the arrow 126, 
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and a visited location register (not shown) associated there- 
with. The routing information is provided to the MSC 26, as 
indicated by the arrow 128. Responsive to the routing 
information, the call is routed from the MSC 26, to the MSC 
24, as indicated by the arrow 130, and thereafter to the 
appropriate base station 18, as indicated by the arrow 132. 
The call is thereafter terminated at the mobile station 122, as 
indicated by the arrow 134. 

FIG. 5 illustrates operation of an embodiment of the 
present invention which permits routing of a call originated 
by a roaming, subscriber unit, here subscriber unit 58, to 
another subscriber unit, here subscriber unit 136, positioned 
in another DECT network, here DECT network 14. The 
roaming, subscriber unit 58 generates a call to the subscriber 
unit 136. The identity of the subscriber unit 58 is indexed 
against a list of permitted roaming subscriber units. The 
subscriber unit 58 is assumed to be listed on the list, and a 
predefined profile is allocated to the subscriber unit. The 
identity of the subscriber unit 136 is also indexed against a 
list of permitted roaming, subscriber units. Here, the sub- 
scriber unit 136 is assumed not to be listed upon the list of 
subscriber units permitted to roam. The call is thereby routed 
as an ordinary call between two DECT networks. 

Operation of the present invention permits wide- area 
mobility management functions provided by a macrocellular 
communication network to be utilized by a microcellular 
communication network to facilitate communication with a 
mobile subscriber. A mobile subscriber regularly registered 
in one microcellular communication network can roam to 
another microcellular communication network and utilize 
the wide-area mobility permitted in a macrocellular com- 
munication network to route calls to the roaming, subscriber 
unit. 

FIG. 6 is an example implementation of the mobility 
management part of the mobility servers 48 and 52 of FIGS. 
1-5. The mobility manager 66 (72) can be, for example, a 
software application executing on the mobility server 48 
(52). The server 48 (52) communicates with the HLR 36 via 
a conventional SS7 signaling channel 65 which passes 
through the associated MSC (not shown in FIG. 6). The 
mobility manager accesses the SS7 signaling channel via a 
conventional communications protocol stack at 61. This 
protocol stack includes the Transaction Capabilities Appli- 
cation Part (TCAP) layer pursuant to ITU-T (International 
Telecommunication Union-Telecommunication Standard- 
ization Sector) Recommendations Q.771, Q.772, Q.773, 
Q.774 and Q.775 which are hereby incorporated herein by 
reference. The protocol stack 61 further includes the Sig- 
naling Connection Control Part (SCCP) according to ITU-T 
Recommendation Q.711, which is hereby incorporated 
herein by reference. The protocol stack 61 further includes 
the Message Transfer Part (MTP) according to ITU-T Rec- 
ommendation Q. 701, which is hereby incorporated herein by 
reference. 

A TCAP API 63 interfaces between the mobility manager 
66 (72) and the TCAP layer of protocol stack 61. The use of 
an API, or Application Programming Interface, to interface 
between a software application and the TCAP layer is well 
known in the art. The TCAP API is conventionally used for 
embedding MAP operations in TCAP messages and, 
conversely, for removing embedded MAP operations from 
TCAP messages. 

The TCAP layer itself is a well known conventional 
provider of an interface between applications and a network 
layer service, and the SCCP and MTP protocol layers are 
well known examples of network layer service providers. 
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The SCCP and MTP protocol layers conventionally provide 
an interface between the TCAP layer and the conventional 
SS7 (Signaling System Number 7) signaling channel 65, as 
described in ITU-T Recommendation Q.700, which is 
hereby incorporated herein by reference. The protocol stack 
61 translates communication signals input to the TCAP layer 
using TCAP protocol into corresponding signals for trans- 
mission over the SS7 signaling channel 65. The use of the 
SS7 signaling channel to support MAP signaling to the HLR 
is well known in the art. 

One problem with the arrangements illustrated in FIGS. 
1-6 wherein a microcellular network uses SS7 signaling to 
access mobility management features of a macrocelhilar 
network is that the externally applied signaling from the 
microcellular network can disadvantageous^ interfere with 
existing functions of the macrocellular network that are 
supported by SS7 signaling within the macrocellular net- 
work. 

Accordingly, and referencing example FIG. 7, the present 
invention provides a firewall 71 between the mobility server 
48 A and the associated SS7 signaling channel to HLR 36, 
and similarly provides a firewall 71 between the mobility 
server 52A and the associated SS7 signaling channel to HLR 
36. The firewall 71 provides a protective isolation between 
the mobility servers 48 A, 52A and their respective SS7 
signaling channels to HLR 36, so it is possible to avoid the 
aforementioned interference with existing functions. 

FIG. 8 illustrates a more detailed example of the arrange- 
ment of FIG. 7. The mobility servers of FIGS. 7 and 8 are 
designated as 48A and 52A to reflect the difference between 
those mobility servers and the mobility servers of FIGS. 
1-6. The difference between the mobility server 48A(FIG. 
8) and the mobility server 48 (FIG. 6) is best seen by 
comparing FIGS. 6 and 8. In particular, the TCAP API 63 of 
FIG. 6 interfaces with the SS7 signaling channel 65 via the 
protocol stack 61, whereas the TCAP API 63 of FIG. 8 
interfaces with a conventional Ethernet system via a con- 
ventional TCP/IP application 81. The mobility server 48A 
(52 A) of FIGS. 7 and 8 may otherwise be identical to the 
mobility server 48 (52) of FIGS. 1-6. 

The TCP/IP application 81 communicates via Ethernet 
link with another conventional TCP/IP application 83 in the 
firewall 71. Applications 81 and 83 could be linked in any 
desired manner, such as by LAN (Local Area Network) or a 
private intranet. The TCP/IP application 83 provides a 
communications interface between the Ethernet system and 
a communications protocol stack 61A. The protocol stack 
61 A is similar to the above-described conventional protocol 
stack 61, in that it includes the conventional TCAP, SCCP 
and MTP protocol layers. However, the protocol stack 61A 
differs from the protocol stack 61 in that it includes a 
screening function at 85. The screening function 85 can be 
implemented as a software module between the TCP/IP 
application 83 and the conventional TCAP layer as shown in 
FIG. 8, or can be incorporated into the software of the TCAP 
layer The SCCP and MTP layers interface the screened 
TCAP layer with the SS7 signaling channel 65 to MSC and 
HLR. 

The screening function 85 operates to screen the various 
TCAP protocol communications received by firewall 71 
from mobility server 48A. TCAP protocol communications 
or messages are transmitted from TCAP API 63 to protocol 
stack 61 A via TCP/IP applications 81 and 83, as connected 
by the Ethernet link. Only TCAP communications which 
pass the screening function 85 are translated by protocol 
stack 61 A into signals for the SS7 signaling channel 65. 
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Disallowed communications which are caught in the screen- 
ing function 85 are not translated and thus are never per- 
mitted to access the SS7 signaling channel. The screening 
function 85 is transparent to communications passing from 

5 channel 65 toward the mobility server 48A. 

FIG. 13 illustrates one example of how the screening 
function 85 may be implemented either as a separate soft- 
ware module or as part of the TCAP protocol layer of 
protocol stack 61A. When a conventional TCAP protocol 

10 message containing, for example, a MAP operation, is 
received (131), the screening function 85 is implemented at 
133. If desired, the results of the screening function can be 
logged into an appropriate database or databases in the 
protocol layer where the screening is done. For example, 
TCAP communications which pass the screening function 

15 can be stored in a "PASS" database, and TCAP communi- 
cations which fail the screening function can be stored in a 
"FAIL" database. If the TCAP communication fails to pass 
the screening function, then control proceeds from 135 back 
to 131 to await the next TCAP communication. If the TCAP 

20 communication passes the screening function, then that 
communication is permitted to traverse the protocol stack 
through the TCAP layer, the SCCP layer and the MTP layer 
to the SS7 signaling channel 65. The communication is 
signaled into the macrocellular network on the SS7 signaling 

25 channel. 

FIG. 9 illustrates an exemplary portion of the screening 
procedure 133. In particular, FIG. 9 illustrates an example 
screening response when a conventional TCAP Invoke 
request pursuant to ITU-T Recommendations Q.771-Q.775 

30 is received from TCP/IP application 83. When the Invoke 
request is received at 90, it is first determined at 91 whether 
or not the operation to be invoked, (for example, a MAP 
operation) is an allowed operation. If not, then the operation 
is disallowed at 97 and the TCAP communication is not 

35 translated (not allowed to pass through the protocol stack 
61A) to the SS7 signaling channel 65. If the operation to be 
invoked is an allowed operation, then the parameters asso- 
ciated with the operation to be invoked are decoded at 93. 
The decoding will typically involve conventional decoding 

40 techniques according to Abstract Syntax Notation One 
(ASN.l). 

After the parameters have been decoded at 93, a check 
parameter procedure is executed at 94. If the check param- 
eter procedure 94 yields an OK result at 95, then it is 

4 5 determined at 96 whether more parameters are included in 
the Invoke request. If so, then the check parameter proce- 
dure at 94 is executed again for the next parameter. If there 
are no more parameters to be checked at 96, and if all results 
from procedure 94 are OK, then the operation to be invoked 

50 has passed the screening. The screening procedure 133 of 
FIG. 13 can thus continue to perform any other necessary 
screening operations, or permit the Invoke request to 
traverse the TCAP, SCCP and MTP layers to the SS7 
signaling channel 65 in conventional fashion. If the check 

55 parameter procedure 94 yields any result that is not OK at 
95, then the operation to be invoked is disallowed at 97. 

FIG. 10 illustrates one example of the check parameter 
procedure 94 of FIG. 9. It is first determined at 101 whether 
or not the parameter is to be subjected to the screening 

60 process. If not, then an "OK" result is returned at 107. If the 
parameter is to be screened at 101, then it is determined at 
103 whether or not the parameter is an allowed parameter. 
If so, the "OK" result is returned at 107. If the parameter, is 
not an allowed parameter at 103, then a "not OK" result is 

65 returned at 105. 

FIG. 11 illustrates one example of a screening operation 
which can be performed when a conventional TCAP Begin 
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request pursuant to ITU-T Recommendations Q.771-Q.775 allowed to invoke, and a listing of operations that TCAP is 

(termed "TCAP Query with Permission" in IS -41) is not allowed to invoke. The database can, as shown in FIG. 

received from the TCP/IP application 83. In particular, if a 14, be accessed and visually displayed by the firewall 

conventional TCAP Begin request is received at 110, it is workstation, thereby permitting the macrocellular network 

first determined at 111 whether or not the destination address 5 operator freely to move various operations from the allowed 

is an allowed destination address. If not, then the dialogue operations list to the disallowed operations list. The opera- 

conventionally associated with the Begin request is disal- tjons shown in FIG. 14 correspond to conventional MAP 

lowed at 115, and no communication is translated (allowed oper ations. These operations may be included either in the 

to traverse the TCAP SCO> and MTP layers) to the SS7 Qr disa]lowed operations list according to the desire 

signaling channel 65. If the destination address is an allowed 1Q Qf ^ macroce]Mar network rator 

destination address at 111, it is then determined at 113 r 

whether or not the origination address is an allowed origi- . HG- 15 f how * one example of a parameters database 

nation address. If the origination address is not an allowed mclu <? 1D g a list of P^meters which will be screened and a 

origination address at 113, the dialogue is disallowed at 115. hst of parameters which will not be screened. As above, the 

If the origination address is an allowed origination address 1 c OP"*™ *»* ™ u freedom to chan f an ? Parameter from the 

at 113, then the screening procedure 131 can continue to 15 screened llst t0 * c not screened llst * 

perform other screening operations, or the Begin request can FIG. 16 shows an example of a database including valid 

be permitted to traverse the TCAP, SCCP and MTP layers to values for a g iven parameter such as the conventional IMSI 

the SSI signaling channel in conventional fashion. (International Mobile Subscriber Identity) number. The 

FIG. 12 illustrates one example of a screening operation , n database can be displayed as above, and the list of valid 

which can be performed when a conventional TCAP Result 2 ° IMS [ numb< * s caQ be s P ecified 48 a V 1 ™^ of 

request pursuant to ITU-T Recommendations Q.771-Q.775 numbers and ' or as a ran S e or ran S es of ambers. The IMSI 

is received from the TCP/IP application 83. Such a Result number * a Parameter associated with the aforementioned 

request is sent, for example, when the mobility server 48A "update location" operation. 

provides a roaming number in response to a request from 25 FIG- 1? is similar to FIG. 16 but shows a parameter 

HLR. When the Result request is received at 120, any database of valid roaming number values, 

parameters associated therewith (such as a roaming number) FIG. 18 illustrates one example of a database that speci- 

are first decoded at 121 in generally the same manner fies the valid MSC number. As can be seen from the 

discussed above with respect to the decode parameters foregoing description, each mobility server in effect acts as 

procedure at 93 in FIG. 9. After the parameters are decoded 3Q an MSC during mobility management operations. Thus, 

at 121, the check parameter procedure 94 of FIGS. 9 and 10 each mobility server has associated therewith an MSC 

is performed. If the check parameters procedure returns a number. Because a given firewall 71 typically communicates 

"not OK" result at 125, then the Result is disallowed at 123, with only one mobility server, the database of FIG. 18 will 

and no communication is permitted to traverse the TCAP, typically have only a single entry, namely the MSC number 

SCCP and MTP layers to the SS7 signaling channel 65. 35 of the mobility server associated with the firewall. The MSC 

If the check parameter procedure returns an "OK" result number is a parameter of the aforementioned "update loca- 

at 125, then it is determined at 127 whether or not any tion" operation. 

parameters remain to be checked. If so, then the check FIG. 19 is similar to FIG. 18, but illustrates a database for 

parameter procedure at 94 is performed again with respect to a valid VLR number. Because each mobility server acts as 

the next parameter. When there are no more parameters to be 40 an MSC, it also has a VLR number. Again, a given firewall 

checked at 127, the Result associated with the Result request will typically have associated therewith only one mobility 

can traverse the TCAP, SCCP and MTP layers to reach the server (see FIG. 7), so the database of FIG. 19 will typically 

SS7 signaling channel 65, If the check parameter procedure have only one entry. The VLR number is a parameter of the 

94 returns a "not OK" result for any parameter, then the aforementioned "update location" operation. 

Result is disallowed at 123 and no communication is per- 45 FIGS. 20 and 21 illustrate respectively the database for 

mitted to traverse the TCAP, SCCP and MTP layers to reach valid origination addresses and the database for valid des- 

the SS7 signaling channel. tination addresses. The origination address of FIG. 20 

The firewall 71 of FIGS. 7-13 can be advantageously includes an Origination Point Code OPC, an Origination 

implemented in a suitable conventional workstation such as SubSystemNumber SSN, and an Origination Global Title 

is commercially available from, for example, Sun Micro- 50 GT, and the destination address of FIG. 21 includes a 

systems. The necessary hardware and software for imple- Destination Point Code DPC, a Destination SubSystem- 

menting the conventional protocol stack 61 are commer- Number DSSN and a Destination Global Title DGT For a 

cially available from, for example, Ericsson Infotech, and given firewall 71, the only valid origination address will be 

the above-described screening procedures can be readily the address of the associated mobility manager, and the only 

implemented either in the software of the TCAP layer of 55 valid destination address will be the address of the HLR. 

conventional protocol stack 61, or as a software module Accordingly, the databases in FIGS. 20 and 21 will each 

between TCP/IP application 83 and the TCAP layer. A typically need only a single entry. 

conventional connection board for making the connection 87 All of the databases of FIGS. 15-21 can be easily 

between the MTP layer and the SS7 signaling channel 65 is accessed and modified in the same general manner as 

also commercially available from AD AX. 60 described above relative to FIG. 14. 

Below are described various databases which can be The above-described databases of FIGS. 14-21, when 

maintained within the screening function of FIG. 8. The utilized in conjunction with the above-described screening 

information in these databases is used in the screening operations of FIGS. 9-13, permit the firewalls 71 of FIGS, 

operations discussed above relative to FIGS. 9-13, as will be 7S to screen communications (e.g. MAP communications) 

clear from the following description. 65 from the mobility managers for the protection of the SS7 

FIG. 14 illustrates an example of a TCAP operations signaling channel 65 in the macrocellular network. The 

database including a listing of operations that TCAP is firewall workstation can be provided as part of the macro- 
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cellular network, thereby permitting the operator of the 
macrocellular network to control incoming signaling on the 
SS7 signaling channel. Moreover, the firewall can be used to 
control incoming signaling other than the mobility manage- 
ment (e.g. MAP) signaling described above. 

Referring again to FIGS. 2 and 6, each of the mobility 
servers at 48 and 52 includes the communications protocol 
stack 61. In situations where a very large number of mobility 
servers 48 and 52 are required to communicate with HLR, 
the licensing and/or purchasing costs of providing each of 
the mobility servers with the protocol stack 61 can become 
quite significant, as well as installation and maintenance of 
the protocol stacks. For example, some systems may have as 
many as 200 mobility servers, each of which must commu- 
nicate with HLR. It is clearly desirable to reduce the typical 
communications protocol stack licensing costs associated 
with such a system. 

It will also be noted that, in the firewall arrangement of 
FIGS. 7 and 8, each firewall 71 includes a communications 
protocol stack at 61 A, Thus, even though the mobility server 
48A does not include the communications protocol stack 61 
shown in FIG. 6, nevertheless, because each mobility server 
48 A has a firewall 71 associated therewith, the arrangement 
of FIGS. 7 and 8 still requires a communications protocol 
stack for each mobility server. 

Exemplary FIG. 22 illustrates a system wherein a plural- 
ity of mobility servers 48Aand 52A communicate with HLR 
36 via a concentrator 221, The concentrator 221 makes it 
possible for the plural mobility servers to communicate with 
HLR using only one communications protocol stack of the 
type shown at 61 in FIG. 6. 

Exemplary FIG. 23 illustrates the concentrator 221 in 
greater detail. The concentrator 221 includes the conven- 
tional protocol stack 61 of FIG. 6 and a conventional TCP/IP 
application 239, and a traffic handler 237 interfacing 
between the TCP/IP application 239 and the communica- 
tions protocol stack 61. The MTP layer of stack 61 is 
connected to the SS7 signaling channel via the conventional 
connection 87 of FIG. 8. The SS7 signaling channel then 
communicates with another conventional protocol stack 61 
in HLR 36. As shown in FIG. 23, the concentrator 221 may 
interface a plurality of mobility servers 48A to any desired 
server 235, for example, a centralized debit platform. In 
addition, the clients of the concentrator 221 need not be 
mobility servers as shown in FIGS. 22 and 23, but could be 
any plurality of clients that require access to a centralized 
server such as shown at 235. 

The traffic handler 237 includes an SSN/Socket portion 
231 and a Dialogue ID portion 233. The SSN/Socket section 
231 tracks the SubSystemNumbers (SSNs) which the mobil- 
ity servers 48A use to identify themselves in their TCAP 
messages. Such use of SSNs in TCAP messages is well 
known in the art. Also well known in the art is the use of 
socket identification (Socket ID) by a TCP/IP server appli- 
cation to identify various TCP/IP client applications. In FIG. 
23, the TCP/IP application 239 functions as a server 
application, and the TCP/IP applications 81 in the mobility 
servers 48A function as client applications. The TCP/IP 
server application 239 is coupled to the plurality of TCP/IP 
client applications 81 via a suitable communication network 
2301 such as Ethernet, or a local area network (LAN) or a 
private intranet. 

The SSN/Socket section 231 correlates between the 
Socket IDs used by the TCP/IP server application 239 and 
the SSNs used by the mobility servers to identify themselves 
in TCAP messages. Upon initialization of the FIG. 23 
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system, each mobility server 48A sends an initializing TCAP 
message from its client application 81 to the server appli- 
cation 239. The initializing TCAP message includes the SSN 
that identifies the particular mobility server. Upon receiving 

5 the initializing TCAP message, server application 239 
assigns a Socket ID to the mobility server from which the 
message originated. The SSN/Socket section 231 then stores 
in a database the relationship between the SSN supplied by 
the mobility server and the Socket ID assigned by the server 

10 application 239. FIG. 30 shows an example of such a 
database including the relationship between the SNNs and 
the Socket IDs. As the initializing TCAP messages are 
received from the various mobility servers 48A, the SSN/ 
Socket section 231 fills in the database of FIG. 30. 

15 In addition to establishing the database of FIG. 30, the 
SSN/Socket function 231 provides the server application 
239 with the appropriate Socket ID when a TCAP message 
from the protocol stack 61 is presented to the server appli- 
cation 239 for transmission to a mobility server 48A. Such 

20 a TCAP message would have originated at the server 235, 
passed to the concentrator 221 via the SS7 signaling 
channel, and arrived at the SSN/Socket section 231 in the 
form of a TCAP message having the conventional SSN to 
identify the mobility server 48A to which the message is 

25 directed. The SSN/Socket function 231 uses the SSN from 
the TCAP message to determine from the database of FIG. 
30 the appropriate Socket ID. This Socket ID is then passed 
to the server application 239, whereupon the server appli- 
cation 239 can forward the TCAP message to the appropriate 

30 mobility server 48A. The above described exemplary opera- 
tion of the SSN/Socket section 231 is illustrated in example 
FIG. 26. At 261, the SSN/Socket portion 231 stores the 
one-to-one relationships between the SSNs and the Socket 
IDs (see FIG. 30) as the Socket IDs are assigned. Thereafter, 

35 when a TCAP message is received (263) from the protocol 
stack of concentrator 221, the Socket ID is determined from 
the SSN at 265. The database of FIG. 30 is used to determine 
the Socket ID from the SSN. After the Socket ID has been 
determined at 265, it is passed to the TCP/IP server appli- 

40 cation 239 along with the TCAP message (267). 

Referring now to the DIALOGUE ID section 233 of the 
traffic handler 237 in FIG. 23, this section pertains to the 
Dialogue ID portion of a conventional TCAP message. This 
portion of a TCAP message identifies the communication, or 

45 dialogue, of which the TCAP message forms a part. As an 
example, a conventional TCAP message from one of the 
mobility servers would include the SSN to identify the 
server from which the message originated, and would also 
include in the Dialogue ID portion a Dialogue ID value to 

50 identify the particular communication, or dialogue, of which 
that message forms a part. Because there are many clients 
(e.g. mobility servers) connected to the concentrator 221, 
and because they carry on their TCAP communications 
independently of one another, two or more of the clients may 

55 select the same Dialogue ID value when composing a TCAP 
message. The DIALOGUE ID section 233 uniquely identi- 
fies each dialogue from each client so that the server 235 can 
keep track of all of the on-going dialogues with the various 
clients. 

60 In the description that follows, the term "Client ID" will 
refer to a Dialogue ID value assigned by a client or the 
DIALOGUE ID section 233 to a TCAP communication 
occurring between the client and the DIALOGUE ID section 
233, and the term "Stack ID" will refer to a Dialogue ID 

65 value assigned by the DIALOGUE ID section 233 to a 
TCAP communication occurring between the DIALOGUE 
ID section 233 and the server 235. 
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The DIALOGUE [D section 233 maintains a Dialogue ID 
database such as shown, for example, in FIG. 29. If C1-C2 
in FIG. 29, then this means that the client having SSN=10 
has assigned the same Dialogue ID value to its communi- 
cation as has the client having SSN=20. However, the 5 
DIALOGUE ID section 233 removes the confusion for the 
server 235 by assigning unique Stack IDs (SI and S2) which 
permit the server 235 to distinguish between the two com- 
munications. 

FIGS. 27 and 28 illustrate one example of possible 10 
operation of the DIALOGUE ID function 233. In the DIA- 
LOGUE ID operation of FIG. 27, it is first determined at 271 
whether a TCAP message has been received. If so, it is then 
determined at 273 whether the TCAP message is received 
from the stack 61 of concentrator 221 or from one of the 15 
clients 48A. If the TCAP message is from a client, it is then 
determined at 275 whether the TCAP message is beginning 
a new dialogue. If the message does represent the beginning 
of a new dialogue, then the DIALOGUE ID function 233 
assigns a new (i.e. not in the FIG. 29 database) Stack ID at 20 
277. Thereafter, at 279, the SSN and Client ID from the 
received TCAP message are stored in a correlating relation- 
ship to the newly assigned Stack ID, as shown in FIG. 29. 
As mentioned above, two or more clients can conceivably 
assign the same Client ID in a TCAP message, so the 25 
DIALOGUE ID section 233 must correlate the Client ID and 
Stack ID to the SSN of the client that originated the message. 
After storing the Client ID -Stack ID relationship, the Stack 
ID is at 2701 inserted into the Dialogue ID portion of the 
TCAP message in place of the Client ID, 30 

If it is determined at step 275 that the TCAP message is 
not beginning a new dialogue, then at 2700 the Client ID and 
SSN are obtained from the TCAP message and are used to 
determine the Stack ID from the FIG. 29 database. Then the 
Stack ID is at 2701 inserted into the Dialogue ID portion of 35 
the TCAP message in place of the Client ID. If it is 
determined at 2703 that the TCAP message is ending a 
dialogue, then at 2705 the Client ID-Stack ID relationship is 
deleted from the database of FIG. 29, including the corre- 
sponding SSN. Thereafter, the DIALOGUE ID section 233 40 
passes the TCAP message to the communications protocol 
stack 61 at 2707. This step 2707 follows immediately after 
step 2703 if it is determined at step 2703 that the TCAP 
message is not ending a dialogue. After passing the TCAP 
message to the stack at 2707, control returns to 271 to await 45 
arrival of another TCAP message. 

Returning to decision block 273, if the TCAP message 
was received from the stack 61 of concentrator 221, control 
flows to point A in FIG. 28. At 281 it is determined whether 
or not the received TCAP message is beginning a new 50 
dialogue. If not, then at 283 the DIALOGUE ID section 233 
inspects the Dialogue ID portion of the TCAP message, 
which will contain the Stack ID, and then uses the Stack ID 
to determine the Client ID from the FIG. 29 database. The 
Client ID is then inserted into the Dialogue ID portion of the 55 
TCAP message at 285. It is thereafter determined at 287 
whether the TCAP message is ending a dialogue. If so, then 
the Client ID-Stack ID relationship (including the SSN) is 
deleted from the FIG. 29 database at 289, after which the 
TCAP message is passed to the client at 2807. If the dialogue 60 
is not ending at 287, then the TCAP message is passed to the 
client at 2807. From step 2807, control returns to point B in 
FIG. 27 and ultimately to 271 to await another TCAP 
message. 

If the received TCAP message is beginning a new dia- 65 
logue at 281 , then at 2805 the Dialogue ID value found in 
the Dialogue ID portion of the TCAP message (which 



Dialogue ID value was in this case assigned by server 235 
of FIG. 23) is assigned to be the Stack ID, and a new Client 
ID is assigned. Any Client ID that is not currently listed in 
the database of FIG. 29 is available as a new Client ID at 
2805. At 2803, the Client ID-Stack ID relationship is stored 
(along with the destination SSN) in the database of FIG. 29. 
Thereafter, at 2807, the TCAP message is passed on to the 
client. Thereafter, control returns to FIG. 27 to await another 
TCAP message at 271. 

FIG. 24 illustrates a plurality of mobility servers at 48A 
and 52A communicating with a server 241 (such as an HLR 
or debit platform) via a concentrator 243 which is connected 
to a bus in common with the mobility, servers and the server 
241. 

FIG. 25 illustrates the example concentrator 243 of FIG. 
24 in more detail. The concentrator 243 of FIG. 25 is similar 
to the concentrator 221 of FIG. 23, except the concentrator 
243 and the server 241 communicate with one another via 
respective TCP/IP applications 251 and 253 and the com- 
munication network therebetween, as opposed to the SS7 
signaling channel connecting the concentrator 221 and the 
server 235 of FIG. 23. In FIG. 25, the TCP/IP application 
253 functions as a conventional server application and the 
TCP/IP application 251 functions as a conventional client 
application. As in FIG. 23, the TCP/IP applications commu- 
nicate with one another via communication network 2301 
such as Ethernet, local area network (LAN) or a private 
intranet. 

Because of the TCP/IP link between concentrator 243 and 
server 241, the communications between concentrator 243 
and server 241 may be conducted with or without their 
respective MTP layers. That is, only the TCAP and SCCP5 
layers of concentrator 243 and server 241 are needed. 
Moreover, if the server 241 (e.g. HLR or debit platform) 
services only the mobility servers and nothing else, for 
example, in a private system, then only the TCAP layers 
would be needed. 

FIGS. 31 and 32 illustrate databases which are advanta- 
geous in the DIALOGUE ID section 233. The FIG. 31 
database maintains a record of the last Client ID assigned by 
the various clients (clients identified by SSN). FIG. 32 is a 
database holding the last Stack ID assigned by the DIA- 
LOGUE ID section 233. Maintaining a record of the last 
Client IDs and the last Stack ID can simplify the process of 
assigning a new Client ID as at 2805 in FIG. 28 or a new 
Stack ID as at 277 in FIG. 27. 

FIG. 33 illustrates another alternative to the concentrator 
embodiments illustrated in FIGS. 23 and 25. In particular, 
the embodiment in FIG. 33 combines the screening function 
85 of FIGS. 8-21 and the traffic handler 237 of FIG. 23. 
Thus, TCAP messages received from the clients 48A and 
52A of FIGS. 22 and 23 can be screened according to 
techniques described above. TCAP messages that pass the 
screening can then be provided to the DIALOGUE ID 
function. Because the screening function acts only on com- 
munications toward the central server, communications 
toward the clients can pass from DIALOGUE ID section 
233 to SSN/Socket section 231. Because the screening 
function in FIG. 33 will screen messages from plural clients, 
(e.g. plural mobility servers), the database of FIG. 20 (valid 
origination addresses) will in this instance include plural 
entries, as will the databases of FIGS. 18 (valid MSC 
numbers) and 19 (valid VLR numbers). 

The concentrators illustrated in FIGS. 23, 25 and 33 can 
be implemented using a commercially available workstation 
such as available from Sun Microsystems. The SSN/Socket 
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section 231 can be realized as a software module in con- 
junction with the TCP/IP server application 239 which is 
conventionally available in such a workstation. The DIA- 
LOGUE ID function 233 can be implemented as a separate 
software module operating in conjunction with the software 
of the TCAP communications protocol layer, or can be 
implemented as a part of the software of the TCAP layer. 

The throughput capacity of the SS7 signaling channel 65 
may limit the throughput (in terms of TCAP transactions per 
second) of the concentrator 221 (FIG. 23) to a throughput 
level less than the throughput capability of the TCAP layer. 
The TCP/IP link at 251, 253 and 2301 of FIG. 25 permits the 
TCAP layer to operate at its full throughput capability. 

Although exemplary embodiments of the present inven- 
tion have been described above in detail, this does not limit 
the scope of the invention, which can be practiced in a 
variety of embodiments. 

What is claimed is: 

1. An interface for connection between a server in a 
macrocelmlar communication network and a plurality of 
client applications in respective microcellular communica- 
tion networks which are relatively smaller than the macro- 
cellular communication network, comprising: 

a first interface portion for connection to the microcellular 

communication networks; 
a second interface portion for connection to the server; 

and 

an apparatus coupled between said first and second inter- 
face portions and implementing a communications pro- 
tocol stack including a plurality of communications 
protocol layers between said first and said second 
interface portions, said communications protocol layers 
including a TCAP layer, said apparatus including a 
traffic handler that permits all of the client applications 
to communicate with the server via said communica- 
tions protocol layers, 

2. The interface of claim 1, wherein said first interface 
portion includes a TCP/IP application. 

3. The interface of claim 1, wherein said traffic handler 
includes a database having assignments between identifica- 
tion numbers used by the respective client applications to 
identify themselves and socket identifications assigned to 
the respective client applications by said first interface 
portion. 

4. The interface of claim 1, wherein said second interface 
portion includes an SS7 signaling channel. 

5. The interface of claim 1, wherein said second interface 
portion includes a TCP/IP application. 

6. The interface of claim 1, wherein said communications 
protocol stack includes a TCAP layer, an SCCP layer and an 
MTP layer. 

7. An interface for connection between a server in a 
macrocelhilar communication network and a plurality of 
client applications in respective microcellular communica- 
tion networks which are relatively smaller than the macro- 
cellular communication network, comprising: 

a first interface portion for connection to the microcellular 

communication networks; 
a second interface portion for connection to the server, 

and 

an apparatus coupled between said first and second inter- 
face portions and implementing a communications pro- 
tocol stack including a plurality of communications 
protocol layers between said first and said second 
interface portions, said apparatus including a traffic 
handler that permits all of the client applications to 
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communicate with the server via said communications 
protocol layers, said traffic handler includes a database 
which correlates between identification codes assigned 
by said traffic handler to respective communications 
5 between the server and the client applications and 
further identification codes assigned to the respective 
communications by the client applications. 

8. The interface of claim 7, wherein said communications 
protocol layer is a TCAP layer, wherein said communica- 

3Q tions include TCAP messages, and wherein said further 
identification codes are parameters of the respective TCAP 
messages. 

9. The interface of claim 7, wherein said traffic handler 
includes a database for storing therein, for each client 
application, a respective one of said further identification 

15 codes most recently assigned by the client application. 

10. The interface of claim 7, wherein said traffic handler 
includes a database for storing therein a most recently 
assigned one of said identification codes. 

U. A method of controlling communications between a 
20 server in a macrocelhilar communication network and a 
plurality of client applications in respective microcellular 
communication networks that are relatively smaller than the 
macrocellular communication network, comprising: 
25 receiving messages enroute between the server and the 
client applications; 
assigning first and second identification codes to each of 
the messages between the server and the client appli- 
cations and matching the first identification codes with 
30 the second identification codes, including selectively 
using the first identification codes to determine the 
respective second identification codes that are matched 
therewith and selectively using the second identifica- 
tion codes to determine the respective first identifica- 
35 tion codes that are matched therewith; 

altering a portion of a message passing between one of the 
client applications and the server, including adding one 
of a first identification code and a second identification 
code into the message; and 
40 sending each of the messages to its destination via a 
communications protocol stack including a plurality of 
communications protocol layers, so that all of the client 
applications are permitted to communicate with the 
server via said plurality of communications protocol 
45 layers. 

12. The method of claim 11, wherein said receiving step 
includes receiving the messages at a communication port, 
and including matching socket identifications assigned by 
the communication port to the respective client applications 

50 with identification numbers used by the respective client 
applications to identify themselves, and said step of sending 
the messages sends the messages based upon the step of 
matching. 

13. The method of claim 12, including using the identi- 
55 fication numbers to determine the respective socket identi- 
fications that are matched therewith, and using the socket 
identifications to determine the respective identification 
numbers that matched therewith. 

14. A method of controlling communications between a 
6Q server in a macrocellular communication network and a 

plurality of client applications in respective microcellular 
communication networks that are relatively smaller than the 
macrocellular communication network, comprising: 

receiving messages enroute between the server and the 
65 client applications; 

assigning first and second identification codes to each of 
the messages between the server and the client appli- 
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cations and matching the first identification codes with 
the second identification codes; 

altering a portion of a message passing between one of the 
client applications and the server, including adding one 
of a first identification code and a second identification s 
code into the message; and 

sending each of the messages to its destination via a 
communications protocol stack including a plurality of 
communications protocol layers, so that all of the client 
applications are permitted to communicate with the 10 
server via said plurality of communications protocol 
layers; 

wherein said sending step includes using an SS7 signaling 
channel to send the messages. 

15. The method of claim 11, wherein said sending step 15 
includes using a TCP/IP application to send the messages. 

16. The method of claim 11, wherein the step of altering 
a portion of a message alters the portion of the message 
passing from one of the client applications to the by adding 
one of said first identification codes into the message. 20 

17. The method of claim 16, wherein said portion is a 
dialogue identification portion of a TCAP message. 

18. The method of claim 16, wherein the step of altering 
a portion of a alters a portion of a message passing from the 
server to one of the client applications by adding one of said 25 
second identification codes into the message passing from 
the server to the one of the client applications. 

19. A method of controlling communications between a 
server in a macrocellular communication network and a 
plurality of client applications in respective microcellular 30 
communication networks that are relatively smaller than the 
macrocellular communication network, comprising: 

receiving messages enroute between the server and the 
client applications, ^ 

assigning first and second identification codes to each of 
the messages between the server and the client appli- 
cations and matching the first identification codes with 
the second identification codes; 

altering a portion of a message passing between one of the 4Q 
client applications and the server, including adding one 
of a first identification code and a second identification 
code into the message; and 

sending each of the messages to its destination via a 
communications protocol stack including a plurality of 45 
communications protocol layers, so that all of the client 
applications are permitted to communicate with the 
server via said plurality of communications protocol 
layers; 

wherein the step of altering a portion of message alters the 50 
portion of a first message passing from one of the client 
applications to the server by adding one of said first 
identification codes into the first message, and alters a 
portion of a second message passing from the server to 
one of the client applications by adding one of said 55 
second identification codes into the second message 
passing from the server to the one of the client appli- 
cations; 

wherein said portions are dialogue identification portions 
of respective TCAP messages. 60 

20. The method of claim 11, wherein the step of altering 
a portion of a message alters the portion of the message 
passing from the server to one of the client by adding one of 
said second identification codes into the message. 

21. A communication system, comprising: 65 
a plurality of microcellular communication networks 

including respective client applications; 



a macrocellular communication network that is relatively 
larger than said microcellular networks, said macrocel- 
lular network including a server; and 

an interface coupled between said server and said plural- 
ity of microcellular networks, said interface including 
a first communication interface coupled to said micro- 
cellular communication networks, a second communi- 
cation interface coupled to said server, and an apparatus 
coupled between said first and second communication 
interfaces and implementing a communications proto- 
col stack including a plurality of communications pro- 
tocol layers between said first and second communica- 
tion interfaces, said apparatus including a traffic 
handler that permits all of the client applications to 
communicate with the server via said communications 
protocol layers, said traffic handler matches identifica- 
tion codes assigned by said traffic handler to respective 
communications between the server and the client 
applications and further identification codes assigned to 
the respective communications by the client applica- 
tions. 

22. The system of claim 21, including an SS7 signaling 
channel connected between said interface and said server, 
said microcellular networks each including a TCP/IP 
application, said interface including a further TCP/IP 
application, said TCP/IP applications of said microcellular 
networks coupled to said farther TCP/IP application. 

23. The system of claim 22, wherein said further TCP/IP 
application is a server application and said TCP/IP applica- 
tions of said microcellular networks are client applications. 

24. The system of claim 21, wherein each of said micro- 
cellular networks includes a TCP/IP application, said inter- 
face includes first and second TCP/IP applications, and said 
server includes a TCP/IP application, said TCP/IP applica- 
tions of said microcellular networks coupled to said first 
TCP/IP application of said interface, and said TCP/IP appli- 
cation of said server coupled to said second TCP/IP appli- 
cation of said interface. 

25. The system of claim 24, wherein said first TCP/IP 
application is a server application and said second TCP/IP 
application is a client application. 

26. An interface for connection between a server in a 
macrocellular communication network and a plurality of 
client applications in respective microcellular communica- 
tion networks which are relatively smaller than the macro- 
cellular communication network, comprising: 

a first interface portion for connection to the microcellular 

communication networks; 
a second interface portion for connection to the server; 

and 

an apparatus coupled between said first and second inter- 
face portions and implementing a communications pro- 
tocol stack including a plurality of communications 
protocol layers between said first and said second 
interface portions, said apparatus including a traffic 
handler that permits all of the client applications to 
communicate with the server via said communications 
protocol layers, said communications protocol stack 
selectively prohibits some communications from the 
client applications from passing through said commu- 
nications protocol stack to the server. 

27. An interface for connection between a server in a 
macrocellular communication network and a plurality of 
client applications in respective microcellular communica- 
tion networks which are relatively smaller than the macro- 
cellular communication network, comprising: 

a first interface portion for connection to the microcellular 
communication networks; 
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a second interface portion for connection to the server; 
and 

an apparatus coupled between said first and second inter- 
face portions and implementing at least one commu- 
nications protocol layer between said first and second 
interface portions, said apparatus including a traffic 
handler that permits all of the client applications to 
communicate with the server via said communications 
protocol layer, wherein said second interface portion 
includes an SS7 signaling channel. 

28. An interface for connection between a server in a 
macrocellular communication network and a plurality of 
client applications in respective microcellular communica- 
tion networks which are relatively smaller than the macro- 
cellular communication network, comprising: 

a first interface portion for connection to the microcellular 
communication networks; 

a second interface portion for connection to the server; 
and 20 

an apparatus coupled between said first and second inter- 
face portions and implementing at least one commu- 
nications protocol layer between said first and second 
interface portions, said apparatus including a traffic 
handler that permits all of the client applications to 25 
communicate with the server via said communications 
protocol layer, wherein said communications protocol 
layer is a TCAP layer. 

29. A method of controlling communications between a 
server in a macrocellular communication network and a 30 
plurality of client applications in respective microcellular 
communication networks that are relatively smaller than the 
macrocellular communication network, comprising: 

receiving messages enroute between the server and the 
client applications; and 

assigning first and second identification codes to each of 
the messages between the server and the client appli- 
cations and matching the first identification codes with 
the second identification codes, including selectively 
using the first identification codes to determine the 
respective second identification codes that are matched 
therewith and selectively using the second identifica- 
tion codes to determine the respective first identifica- 
tion codes that are matched therewith; 

sending each of the messages to its destination via a 
common communications protocol layer, using an SS7 
signaling channel to send the communications. 

30. A communication system, comprising: 
a plurality of microcellular communication networks 

including respective client applications; 

a macrocellular communication network that is relatively 
larger than said microcellular networks, said macrocel- 
lular network including a server; 

an interface coupled between said server and said plural- 55 
ity of microcellular networks, said interface including 
a first communication port coupled to said microcellu- 
lar communication networks, a second communication 
port coupled to said server, and an apparatus coupled 
between said first and second communication ports and 60 
implementing a communications protocol layer 
between said first and second communication ports, 
said apparatus including a traffic handler that permits 
all of the client applications to communicate with the 
server via said communications protocol layer, and 
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an SS7 signaling channel connected between said inter- 
face and said server, said microcellular networks each 
including a TCP/IP application, said interface including 
a further TCP/IP application, said TCP/IP applications 
of said microcellular networks coupled to said further 
TCP/IP application. 

31. The system of claim 30, wherein said further TCP/IP 
application is a server application and said TCP/IP applica- 
tions of said microcellular networks are client applications. 

32. The system of claim 21, wherein said communications 
protocol stack selectively prohibits some communications 
from the client applications from passing through said 
communications protocol stack to the server. 

33. A method of controlling communications between a 
server in a macrocellular communication network and a 
plurality of client applications in respective microcellular 
communication networks that are relatively smaller than the 
macrocellular communication network, comprising: 

receiving messages enroute between the server and the 
client applications; 

assigning first and second identification codes to each of 
the messages between the server and the client appli- 
cations; 

sending, using the corresponding first and second identi- 
fication codes, each of the messages to its destination 
via a communications protocol stack including a plu- 
rality of communications protocol layers, so that all of 
the client applications are permitted to communicate 
with the server via said plurality of communications 
protocol layers; and 

selectively prohibiting some communications between the 
client applications and the server from passing through 
said communications protocol stack; 

wherein the first identification codes comprise socket 
identifications and the second identification codes com- 
prise subsystem number identifications. 

34. A method of controlling communications between a 
server in a macrocellular communication network and a 
plurality of client applications in respective microcellular 
communication networks that are relatively smaller than the 
macrocellular communication network, comprising: 

receiving messages enroute between the server and the 

client applications; 
assigning first and second identification codes to each of 
the messages between the server and the client appli- 
cations and matching the first identification codes with 
the second identification codes; 
altering a portion of a message passing between one of the 
client applications and the server, including adding one 
of a first identification code and a second identification 
code into the message; and 
sending each of the messages to its destination via a 
communications protocol stack including a plurality of 
communications protocol layers, so that all of the client 
applications are permitted to communicate with the 
server via said plurality of communications protocol 
layers; 

wherein the first identification codes comprise client 
identifications and the second identification codes com- 
prise DIALOGUE identifications. 
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